Hace dos años, el carbon-aware scheduling era experimental y activado manualmente por equipos motivados por sostenibilidad o presión regulatoria. A principios de 2026, con varias distribuciones de Kubernetes y plataformas gestionadas incorporándolo como opción por defecto o muy visible, toca evaluar si la promesa se cumple en la práctica. La hipótesis de base, que decidir dónde y cuándo ejecutar cargas según la intensidad de carbono de la red eléctrica reduce emisiones sin penalizar rendimiento significativamente, ha tenido tiempo suficiente para probarse y generar datos reales. Qué dicen esos datos y dónde están las grietas es lo que toca revisar.
Qué es carbon-aware scheduling en 2026
La idea fundamental es simple. La intensidad de carbono de la electricidad (gramos de CO2 por kilovatio hora) varía significativamente a lo largo del día y entre regiones, según qué fuentes estén generando en cada momento. Las redes con mucha eólica o solar tienen periodos de alta limpieza cuando hace viento o sol, y periodos de alta suciedad cuando dominan gas y carbón. Mover cargas elásticas a regiones o horas más limpias reduce emisiones sin cambiar la cantidad de trabajo hecho.
El patrón técnico consolidado en 2026 combina varios componentes. Un medidor de consumo energético por carga (Kepler para Kubernetes es la referencia abierta), una fuente de datos de intensidad de carbono en tiempo real (Electricity Maps, WattTime, APIs de proveedores), un planificador que integra esta información en sus decisiones (kube-scheduler con extensiones carbon-aware, o planificadores de plataforma como Karpenter con políticas específicas) y métricas de seguimiento que permiten verificar impacto real.
Google Cloud, Azure y AWS han integrado carbon-aware en sus servicios gestionados durante 2024 y 2025. Google Kubernetes Engine ofrece clusters con planificador carbon-aware como opción. Azure Sustainability Dashboard muestra intensidad de carbono por región y permite políticas automáticas. AWS tiene similar desde 2024 aunque con menos énfasis mediático. El ecosistema abierto, con Kepler graduado en CNCF a finales de 2024 y Green Software Foundation aportando estándares (Software Carbon Intensity, SCI), permite implementar el patrón también sobre infraestructura propia.
Dónde ha funcionado mejor
Los casos donde el carbon-aware scheduling ha aportado reducciones reales de emisiones tienen un patrón común: cargas de trabajo que toleran flexibilidad temporal o geográfica sin degradar experiencia del usuario. Procesamiento batch nocturno, entrenamiento de modelos de aprendizaje, compilación y testing de código en CI, generación de informes y analítica, rederizado de vídeo y similares. Estas cargas se pueden retrasar unas horas o mover entre regiones sin que nadie se dé cuenta.
En estos escenarios, empresas que han adoptado carbon-aware con seriedad reportan reducciones reales de emisiones entre 15 y 30 por ciento según el caso. Un ejemplo concreto que he visto es un entrenamiento diario de modelos de personalización en una empresa de e-commerce. El trabajo dura varias horas y no tiene SLA de horario. Moviendo su ejecución automáticamente a la ventana más limpia del día (normalmente entre tarde y noche cuando la solar todavía genera y la demanda baja) se reduce la intensidad de carbono del trabajo alrededor del veinte por ciento respecto a ejecutarlo por la mañana como hacía antes.
Otro caso interesante son trabajos de CI distribuidos entre regiones geográficas. Algunos proveedores ofrecen runners de CI que ejecutan el job en la región disponible con menor intensidad de carbono en ese momento. Para un equipo con miles de builds al mes, este cambio suma: si Estocolmo está con hidroeléctrica al máximo y Dublín con eólica fuerte, el job va allí en vez de a una región con mix de carbón. Las reducciones acumuladas a lo largo del año son medibles y el coste operativo adicional es prácticamente nulo.
Dónde el ahorro es marginal o inexistente
El otro lado de la historia son los casos donde carbon-aware scheduling aporta muy poco o nada. Aplicaciones en línea con usuarios activos no se pueden mover geográficamente sin añadir latencia, y no se pueden retrasar sin degradar experiencia. APIs de producción, servicios web orientados a tráfico real, bases de datos transaccionales: todo esto ejecuta cuando hace falta, donde el usuario está, y el carbon-aware scheduling no tiene palancas que mover sin afectar servicio.
En un análisis de un despliegue que revisé recientemente, más del ochenta por ciento del consumo energético total correspondía a cargas no diferibles. Al aplicar carbon-aware solo a la fracción restante, el ahorro total del cluster fue inferior al cinco por ciento, una cifra real pero bastante por debajo de lo que marketing de los proveedores sugería. La lectura honesta es que el beneficio es proporcional a qué fracción de tu carga es elástica, no a que actives la función.
También hay casos donde el carbon-aware puede producir resultados contraproducentes si se aplica sin pensar. Mover cargas a regiones lejanas con mejor mix puede aumentar emisiones netas si el tráfico de datos entre centros crece notablemente; la transferencia también consume energía. Retrasar trabajos para esperar ventanas limpias puede aumentar coste operativo si requiere mantener recursos reservados o si acumula presión en horarios específicos. La optimización sin medición cuidadosa puede salir peor que dejar el planificador por defecto.
El problema de la medición honesta
Un desafío central del carbon-aware scheduling es medir con precisión cuánto CO2 realmente se ahorra. La intensidad de carbono reportada por APIs como Electricity Maps o WattTime es aproximación razonable pero no perfecta, con retraso de actualización, granularidad limitada (región completa, no subcentro), y diferencias metodológicas entre proveedores. Dos herramientas que miden el mismo caso pueden reportar cifras diferentes en un 10 o 20 por ciento.
Kepler en Kubernetes ha mejorado mucho desde su graduación en la CNCF, pero sigue teniendo limitaciones. El consumo por pod se estima desde métricas del procesador, memoria y disco aplicando modelos de consumo energético que no siempre reflejan bien hardware nuevo o específico. Las mediciones tienen error conocido de hasta 20 por ciento en cargas mixtas, y los ratios de atribución entre procesos que comparten máquina son aproximaciones. Esto no invalida la herramienta, pero sí obliga a interpretar sus cifras como indicaciones, no como verdades exactas.
La Software Carbon Intensity de Green Software Foundation es un estándar útil para normalizar medición y comparación entre sistemas, pero su adopción real sigue siendo limitada. Menos del 30 por ciento de despliegues que he revisado reportan SCI como métrica, y menos aún establecen objetivos basados en esta métrica. El problema es cultural tanto como técnico: la mayoría de equipos no tienen incentivos claros para optimizar esta métrica frente a otras más inmediatas como coste o latencia.
Un ejemplo práctico con Karpenter
Un patrón que he visto funcionar bien en 2026 combina Karpenter (autoescalado de Kubernetes basado en nodos) con políticas carbon-aware. La idea es preferir regiones con menor intensidad para aprovisionamiento de nodos nuevos cuando el escenario lo permite, manteniendo restricciones de latencia para cargas sensibles. Un fragmento simplificado de política:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: batch-carbon-aware
spec:
template:
spec:
requirements:
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["c", "m"]
- key: topology.kubernetes.io/region
operator: In
values: ["eu-north-1", "eu-west-1", "eu-central-1"]
taints:
- key: batch
effect: NoSchedule
weight: 100
providerRef:
name: carbon-intensity-preferenceLa política anterior, combinada con un controlador que actualiza un peso basado en intensidad de carbono por región y hora, mueve la preferencia de Karpenter dinámicamente. Las cargas que tienen tolerancia al taint “batch” se planifican en la región con mejor mix en ese momento. En un despliegue que monitorizo, esta política aplicada a entrenamientos y procesamiento nocturno redujo la intensidad media en el entorno de entre 20 y 25 por ciento tras tres meses.
Cuándo compensa
A principios de 2026, con carbon-aware scheduling dejando de ser experimental y pasando a ser capacidad estándar de plataformas maduras, la recomendación práctica es medida. Primero, identifica honestamente qué fracción de tu carga es realmente elástica en tiempo o geografía; si menos del 20 por ciento lo es, el ahorro total será modesto. Segundo, calcula coste de implementación y medición contra beneficio esperado; para algunos equipos el esfuerzo supera el ahorro potencial.
Tercero, si decides adoptarlo, invierte en medición honesta con Kepler, Software Carbon Intensity o equivalente, y verifica las cifras con datos reales en vez de confiar en lo que promete la plataforma por marketing. La integridad intelectual de reportar ahorros reales y reconocer limitaciones es más valiosa a largo plazo que cualquier cifra inflada de emisiones evitadas.
Cuarto, considera el carbon-aware scheduling como una pieza entre varias de una estrategia de sostenibilidad técnica. La arquitectura eficiente, el rightsizing de recursos, el apagado de infraestructura ociosa, la optimización de código, la elección de lenguaje de ejecución, la selección de hardware eficiente y la renovación hacia hardware moderno con mejor eficiencia energética producen ahorros típicamente mayores que el carbon-aware solo. No es o uno o lo otro; es combinar todos los frentes. En 2026, con la tecnología disponible y la capacidad operativa madura, no hacerlo empieza a ser difícil de justificar, pero hacerlo con honestidad sobre límites y medición seria es la única aproximación que produce resultados duraderos y creíbles.
